The value bound to a variable when a function employing that variable is evaluated depends upon the scoping technique employed by the computer programming language. Static scoping and dynamic scoping are two known scoping techniques.
In static scoping, a name always refers to the innermost lexically apparent assignment of a value to the name. That is, the function gets the value of the name from the environment in which the function is defined.
In contrast, in dynamic scoping a name gets its value from the environment in which the function is applied, or called.
The difference between static scoping and dynamic scoping is illustrated by the following example.
______________________________________ 9 LET 10 {x = 3; 20 f = FUNCTION ... IN x + x} 25 IN 30 LET {x = 4} 40 IN f() ______________________________________
The value computed by the application of the function f at line 40 depends upon the type of scoping employed.
As a first example, in the event that static scoping is employed, the value of f( ) at line 40 is 6, because the value of the name x is taken from the environment of the function definition. In the environment of the function definition, x is bound to 3 at line 10.
As a second example, in the event that dynamic scoping is employed, the value of f( ) at line 40 is 8, because the value of x is taken from the environment in which the function application occurs. In the environment of the function application, x is bound to 4 at line 30.
When a language is used to write configuration descriptions the question of the method of scoping becomes critical. A language is used to write configuration descriptions in order to control a "build" operation. In a build operation, software modules are compiled and linked in order to produce an executable file. The software modules may be written in various languages such as C, C++, assembly language, etc., and the configuration management language is used to write a description of operations which are applied to the software modules as they are built into a single executable file. Typically, the software modules may have over a million lines of code, and there may be tens or hundreds of individual people writing various of the software modules.
There are several properties that a configuration description should have.
First, a system description should be complete. All of the information needed to control the build operation must be written down in the description. A complete description permits the build to be reproduced at a later time. A complete description also permits a user to audit the build directly from the configuration description. By reading the description, the user can discover exactly what operations were performed.
Second, the configuration should be concise. Conciseness makes it easier to create new descriptions and to read existing descriptions.
Third, the configuration description should be flexible and easy to modify. For example, it should be possible to change the version of the compiler without having to edit every subsystem in the description. In particular, it should be possible to change the version of the compiler in one place and have the change be effective over the entire description.
Fourth, each modular subsystem of the description should encapsulate essential aspects of the subsystem so that a subsystem cannot be inadvertently changed by another subsystem.
The scoping method of a configuration description language affects its ability to provide these properties. If a language employs dynamic scoping, it can provide the first, second and third of the above properties. If a language employs static scoping, it can provide the fourth of the above properties. A method of scoping which provides all four of the above properties is needed.